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DETAILED ACTION 

1 . Claims 1 -30 are presented for examination. 

Response to Arguments 

2. Applicant's arguments filed 4/15/2005 have been fully considered but they are not 
persuasive. Therefore, rejection of claims 1-30 is maintained. 

Applicant argues, (1) "Zisapel-Radware et al, US Publication, 2002/0103846 Al, "Load 
Balancing", Aug. 1, 2002, Radv^are Limited (Hereinafter Zisapel-Radware) does not teach or 
disclose, a system that assigns a virtual IP address to a scheduler that is designated as active 
scheduler for a load balancing array, wherein request packets are routed via the virtual IP address 
as claimed in claims 1 and 16". The examiner disagrees in response to applicant's arguments. 
The limitations, "a system that assigns a virtual IP address to a scheduler that is designated as 
active scheduler for a load balancing array, wherein request packets are routed via the virtual IP 
address", etc, has been newly added, which is addressed by the new ground(s) of rejection 
(please refer to the below rejections of this office action). Therefore, the rejection is maintained. 

Response to Amendment 

3. The amendment filed 5/6/2005 is objected to under 35 U.S.C. 132 because it introduces 
new matter into the disclosure. 35 U.S.C. 132 states that no amendment shall introduce new 
matter into the disclosure of the invention. The added material which is not supported by the 
original disclosure is as follows: 
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a. addition of limitations, "assigning a virtual IP address to a scheduler", in claims 1 
and 16. 

Applicant is required to cancel the new matter, to avoid abandonment of this application, 
in the reply to this Office Action. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

4. Claims 1 and 16 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply 
with the written description requirement. The claim(s) contains subject matter, which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art to use and/or make the invention. 

The specification does not contain subject matter to implement limitations, "assigning a 
virtual IP address to a scheduler (being load balancing server)", as cited in claims 1 and 16. 
Also, page 7, lines 22-30, of the specification, states "single virtual IP address for many Web 
servers", which has a different scope than the claimed limitations. 

Examiner has reviewed the specification (OCR whole document) and could not find 
support for the additional limitations as claimed. 

The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter, which the applicant regards as his invention. 
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5. Amended claims 1, 3, 1, 16, 18, 22, are rejected under 35 U.S.C. 1 12, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

6. Amended claims 1 and 16, recite the limitations, "load balances said request packet", 
"response packet to said request packet". There is insufficient antecedent basis for this limitation 
in the claim. Due to amendment to the claims, multiple request packets ( request packets from 
requesting clients) exist in the claims 1 and 16. It is not clear which request packet is referred by 
these limitations. 

7. Amended claims 7, 22, recite the limitations, " said request packet". There is insufficient 
antecedent basis for this limitation in the claim. Due to amendment to the claims, multiple 
request packets (request packets fi-om requesting clients) exist in the claims 1 and 16. It is not 
clear which request packet is referred by these limitations. 

8. Amended claims 3,18, recite the limitations, " said load balancing servers ", the new 
scheduler". There is insufficient antecedent basis for this limitation in the claim. 

Claim Rejections - 35 USC §103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made, 

10. Claims 1, 2, 16 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Zisapel et al., US Publication, 2002/0103846 Al, Aug. 1, 2002, "Load Balancing", Radware 
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Limited (Hereinafter Zisapel-Radware) in view of Hassett et al., 61 73,3 1 1 , PointCast Inc 
(Hereinafter Hasett-PointCast) and Bruck et al., 6,801,949, Rainfinity Inc (Hereinafter Bruck- 
Rainfinity). 

11. As per claims 1 and 1 6, Zisapel-Radware clearly teaches a process and an apparatus (e.g., 
figure IC, abstract) to implement routing packets through a load balancing array of servers 
across a network in a computer environment (e.g., router balancing load among cluster of servers 
over the network, figures 1 A - IC, paragraph 33, page 3), 

a scheduler that is designated as active scheduler for a load balancing array (e.g., usage 
of load balancing servers, content servers, SI, Sn, figures 1 A - IC, paragraph 33, page 3); 

wherein request packets fi"om requesting clients destined for the load balancing array are 
routed through said scheduler (e.g., LBl load balancing server also scheduling client requests for 
LB2 load balancing server, figures 1 A - IC, paragraphs 33 and 34, page 3); 

wherein said scheduler routes and load balances a request packet from a client (e.g., 
client requests, paragraphs 33 and 34, page 3) to a load balancing server (e.g., LBl load 
balancing server also scheduling client requests for LB2 load balancing server, figures 1 A - IC, 
paragraph 33, page 3); 

wherein said load balancing server routes and load balances said request packet to a back 
end Web server (e.g., LB2 load balancing server balancing load among content servers, SI, Sn, 
figures 1 A - IC, paragraph 33, page 3); 

wherein said back end Web server's response packet to said request packet is sent to said 
load balancing server (e.g., SI, Sn, content servers supporting client requests through LB2 load 
balancing server, paragraphs 8-10, pagel); and 
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wherein said load balancing server sends said response packet directly to said client (e.g., 
LB2 load balancing server forwarding response from content servers, SI, Sn, to the clients, 
paragraphs 8-10, page 1 ). 

Zisapel-Radware also teaches handling of multiple requests for a client (e.g., paragraph 
36, page 3). 

However, Zisapel-Radware does not specifically mention about a request containing 
multiple packets and a scheduler supporting multiple clients . 

Hasett-PointCast clearly teaches a request containing multiple packets (e.g., abstract, col., 
7, lines 5 - 40, col., 3, lines 34 - 65) and a scheduler supporting multiple clients (e.g., abstract, 
col., 7, lines 5 - 40, coL, 3, lines 34 - 65). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware with Hasett-PointCast in order to 
facilitate the scheduler to support multiple clients because the requests from the multiple clients 
would be processed by the scheduler. A request having multiple packets would help the request 
communicated from a client to the scheduler. The scheduler would receive requests from the 
clients and would forward the requests so that the requests from the clients are properly handled. 

Zisapel-Radware and Hasett-PointCast do not specifically mention about assigning a 
virtual IP address to scheduling object and usage of the virtual IP address. 

Bruck-Rainfinity discloses the concept of assigning a virtual IP address to scheduling 
object (e.g., col., 36, line 26 - col., 37, line 19) and usage of the virtual IP address (e.g., col., 36, 
line26-col., 37, line 19). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
v^as made to combine the teachings of Zisapel-Radware and Hasett-PointCast with Bruck- 
Rainfinity in order to facilitate assigning a virtual IP address to scheduling object and usage of 
the virtual IP address because the scheduling object would use the virtual IP address for 
communicating information to a remote device. The assigned virtual IP address would provide a 
client device to use the object device for processing the request. 

12. As per claims 2 and 17, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity teach 
the claimed limitations as rejected above. Zisapel-Radware also teaches the following: 

scheduler is a load balancing server and routes and load balances client requests to itself 
(e.g., LBl load balancing server scheduling client requests for itself, figures 1 A - IC, paragraph 
33, page 3). 

13. Claims 3, 4, 7, 8, 13, 18, 19, 22, 23 and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in view of "Official 
Notice". 

14. As per claims 3 and 1 8, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity teach 
the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfinity do not specifically mention about the use of detecting the failure of the server 
and electing one of said load balancing servers as the new server. "Official Notice" is taken that 
both the concept and advantages of providing to detect the failure of the server and electing one 
of said load balancing servers as the new server is well known and expected in the art. For 
example, Coile et al., 6,108,300 (Hereinafter Coile) teaches limitations, "detecting the failure of 
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the server and electing one of said load balancing servers as the new server (e.g., col., 5, lines 3 - 
24, e.g., col., 6, lines 40 - 62, col,, 8, lines 2 - 28). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting the failure of the server and electing one of said load balancing 
servers as the new server with the teachings of Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfinity in order to facilitate replacing of scheduler in an event of the scheduler failure because 
upon failure of the scheduler, another load balancing server can take over scheduling task to 
assign servers for the client requests. The another load balancing server will then receive the 
client requests and will process them, i.e., schedule them according to the scheduling algorithm. 

15. As per claims 4 and 19, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity teach 
the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfmity do not specifically mention about the use of server detecting the failure of other 
load balancing servers and the server stops routing packets to any failed load balancing servers. 
"Official Notice" is taken that both the concept and advantages of providing server detecting the 
failure of other load balancing servers and the server stops routing packets to any failed load 
balancing servers, is well known and expected in the art. For example, Coile et al., 6,108,300 
(Hereinafter Coile) teaches limitations, "server detecting the failure of other load balancing 
servers (e.g., col., 12, lines 35 - 54, col., 6, lines 40 - 62, col., 8, lines 2 - 28)" and "the server 
stops routing packets to any failed load balancing servers/back end Web servers (e.g., col., 12, 
lines 35 - 54, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28)". 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include server detecting the failure of other load balancing servers and the server 
stops routing packets to any failed load balancing servers, with the teachings of Zisapel- 
Radware, Hasett-PointCast and Bruck-Rainfinity in order to facilitate assigning client requests to 
another load balancing server instead of the failed load balancing server because stopping to 
route packets to the failed load balancing server would prevent dropping packets. Rerouting to 
the packets to the other load balancing server will help process the client requests. 

16. As per claims 7, 8, 22 and 23, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
teach the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast 
and Bruck-Rainfinity do not specifically mention about the use of server decrypting and 
encrypting packet for an SSL session. "Official Notice" is taken that both the concept and 
advantages of providing server decrypting and encrypting packet for an SSL session, is well 
known and expected in the art. For example, Hankinson et al., 6,799,202 (Hereinafter 
Hankinson) teaches limitations, "server decrypting and encrypting packet for SSL session (e.g., 
col., 3, lines 2 - 65)". 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include server decrypting and encrypting packet for an SSL session, with the 
teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in order to facilitate secure 
conmiunicating between the client and the Web server because for processing and forwarding the 
packet to the Web server, the load balancing server will decrypt the packet when it receives fi"om 
the client. The load balancing server will receive the response packet from the Web server, and 
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it will encrypt the response packet before sending to the client. Using well-known SSL session 
implementation, the web server and the client will have direct secure communication. 

17. As per claims 13 and 28, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity teach 
the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfinity do not specifically mention about the use of detecting and stop routing request 
packets to failed back end Web servers. "Official Notice" is taken that both the concept and 
advantages of providing detecting and stop routing request packets to failed back end Web 
servers is well knovm and expected in the art. For example, Coile et al., 6,108,300 (Hereinafter 
Coile) teaches limitations, "server detecting the failure of other load balancing servers (e.g., col., 
12, lines 35 - 54, col., 6, lines 40 - 62, col., 8, lines 2 - 28)" and "the server stops routing packets 
to any failed load balancing servers/back end Web servers (e.g., col, 12, lines 35 - 54, e.g., col., 
6, lines 40 - 62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting and stop routing request packets to failed back end Web servers 
with the teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in order to 
facilitate accessing the other web server in an event of the web server failure because upon 
failure of the web server, other web server would help support the client requests. By stopping 
to route the packets to the failed web server would help prevent packets from dropping and the 
other web server would then handle the client requests. 
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18. Claims 5, 6, 14, 15, 20, 21, 29, 30, are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in view of Masters 
6,374,300 (Hereinafter Masters). 

19. As per claims 5, 6, 14, 15, 20, 21, 29, 30, Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfmity teach the claimed limitations as rejected above. However, Zisapel-Radware, Hasett- 
PointCast and Bruck-Rainfinity do not specifically mention about the server scheduling sessions 
to servers based on a cookie or session ID and use of cookie injection to map a client to a 
specific server. 

Masters clearly teaches about the concept of server scheduling sessions to servers based 
on a cookie or session ID (e.g., abstract, col., 10, lines 8 - 61), and use of cookie injection to map 
a client to a specific server (e.g., abstract, col., 10, lines 8-61, col., 13, lines 1- 24), modify 
URLs in the HTML page in a packet to serve them from said content delivery network (e.g., col., 
5, linesl4 - 61, col, 3, lines 21 - 50), HTML pages that have modified URLs are cached to 
improve performance (e;g., abstract, coL, 10, lines 8-61, col., 2, lines 24 - page 4, line 34, col., 
7, lines 1-16). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
with Masters in order to facilitate scheduling based on cookie for persistent connection with the 
web server because using the cookie the client request can be routed to a previously selected 
destination web server associated with the client. The client will be able to continue using the 
same web server support. As per Masters teachings, the cookie information can be manipulated 



Application/Control Number: 09/779,07 1 Page 1 2 

Art Unit: 2154 

as necessary. Hence, the client will be able to continue communicating with the server in a 
direct persistent manner. 

20. Claims 9-12, 24-27, are rejected under 35 U.S.C. 103(a) as being impatentable over 
Zisapel-Radware, Hasett-PointCast, Bruck-Rainfmity and "Official Notice" in view of Masters 
6,374,300 (Hereinafter Masters). 

21 . As per claims 9-12, 24-27, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
teach the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast 
and Bruck-Rainfmity do not specifically mention about the client keeping connection alive with 
the server. "Official Notice" is taken that both the concept and advantages of the client keeping 
connection alive with server, is well knovra and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include the client keeping connection alive with the server, with the teachings of 
Zisapel-Radware, Hasett-PointCast and Bruck-Rainfmity in order to facilitate secure 
communicating between the client and the Web server because using well-knovm SSL session 
implementation, the web server and the client will have direct secure communication as long as 
the connection between the web server and the client is alive. 

Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity do not specifically mention 
about URL based scheduling of packets and the load balancing server performing hash 
scheduling of packets. Masters teaches about URL based scheduling of packets (e.g., col., 5, 
lines 18 - 65), persistent connections in its paths when required (e.g., coL, 5, lines 22 - 59, col., 
6, lines 8-31) and the load balancing server performing hash scheduling of packets (e.g., col.. 
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15, lines 45 - coL, 16, lines 21) and uses hash group based persistence to maintain its persistence 
tables (e.g., coL, 5, lines 22 - 59, col., 15, line 57 - col., 16, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
with Masters in order to facilitate secure communicating between the client and the Web server 
because the URL information in the https packet would provide information of the resource, 
which the client needs to access. The scheduling with hashing of packets will provide direct 
secure conununication between the web server and the client. 

Conclusion 

The prior art made of record (forms PTO-892 and applicant provided IDS cited arts) and 
not relied upon is considered pertinent to applicant's disclosure. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone niunber is (571) 272-3973. The 
examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 10:00 am to 
8:00 pm. 

If attempts to reach the examiner by telephone are unsuccessfial, the examiner's 
supervisor, John FoUansbee can be reached on (571) 272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-8300. 
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Information regarding the status of an application may be obtained from the Patent . 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Haresh Patel 
July 22, 2005 

/ j/hN FOLUNSBEE 

S!/<^rr;fe EXAMfNER 
'"^tcmm^ 2100 



